x86: adjust handling of interrupts coming in via legacy vectors

x86: adjust handling of interrupts coming in via legacy vectors

The debugging code added in c/s 24707:96987c324a4f was hit a (small)
number of times (one report being
http://lists.xen.org/archives/html/xen-devel/2012-05/msg00332.html),
apparently always with a vector within the legacy range. Obviously,
besides legacy vectors not normally expected to be in use on systems
with IO-APIC(s), they should never make it to the IRQ migration logic.

This wasn't being prevented so far: Since we don't have a one-to-one
mapping between vectors and IRQs - legacy IRQs may have two vectors
associated with them (one used in either 8259A, the other used in one
of the IO-APICs) -, vector-to-IRQ translations for legacy vectors (as
used in do_IRQ()) would yield a valid IRQ number despite the IRQ
really being handled via an IO-APIC.

This gets changed here - disable_8259A_irq() zaps the legacy vector-to-
IRQ mapping, and enable_8259A_irq(), should it ever be called for a
particular interrupts, restores it.

The spurious interrupt logic in do_IRQ() gets adjusted too: Interrupts
coming in via legacy vectors presumably didn't get reported through the
IO-APIC/LAPIC pair (as we never program these vectors into any RTE or
LVT). Call ack_APIC_irq() only when the LAPIC's ISR bit says an
interrupt is pending at the given vector. Plus, a new function (pointer)
bogus_8259A_irq() gets used to have the 8259A driver take care of the
bogus interrupt (as outside of automatic EOI mode it may need an EOI to
be issued for it to prevent other interrupts legitimately going through
the 8259As from getting masked out).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>